To provide a true full mesh or even dense partial mesh of connectivity, tunnel-based solutions require the provisioning of a complex connectivity mesh. Such a complex mesh not only has higher processor and memory requirements, but is difficult to provision, troubleshoot, and manage.


Cisco‘s Group Encrypted Transport VPN (GETVPN) introduces the concept of a trusted group to eliminate point-to-point tunnels and their associated overlay routing. All group members (GMs) share a common security association (SA), also known as a group SA. This enables GMs to decrypt traffic that was encrypted by any other GM. (Note that IPsec CE acts as a GM.) In GETVPN networks, there is no need to negotiate point-to- point IPsec tunnels between the members of a group, because GETVPN is tunnel-less. The IETF standard RFC-3547 Group Domain of Interpretation (GDOI) is an integral part of GETVPN. The GDOI protocol was introduced in 12.4(2)T but the GET VPN solution with several enhancements was released in 12.4(11)T.

Following are some of the advantages of GETVPN over other VPN technologies.

• Provides highly scalable any to any mesh topology natively and eliminates the need for complex peer-to-peer security associations.

• For Multiprotocol Label Switching (MPLS) networks, maintains network intelligence (such as full-mesh connectivity, natural routing path, and QoS). Grants easy membership control with centralized key servers.

• Helps ensure low latency and jitter by enabling full-time, direct communications between sites, without requiring transport through a central hub.

• GETVPN allows replication of the packets after encryption. This allows the multicast traffic to be replicated at the core, thereby reducing the load and band width requirement on the Customer Premises Equipment (CPE).

• IP Address Preservation enables encrypted packets carry the original source and destination IP addresses in the outer IP header rather than replacing them with tunnel endpoint addresses. This technique is known as IPSec Tunnel Mode with Address Preservation. Some of the IP header parameters are also preserved. Many network features like routing, basic firewall, QoS, traffic management etc. work based on the information contained in the IP header. Since the IP header is persevered, all the network features will work as before. This eliminates lot of issues associated with deploying point to point encryption in a core network



GROUP ENCRYPTED TRANSPORT

  

  

  

GET VPN:

* Suitable only in PRIVATE network, because it preserves original header

* QOS is possible because GETVPN preserves original header

* It eliminates POINT-TO-POINT VPN (site-site), overlay vpn (DMVPN)


Centralized location for interesting traffic

      Cisco‘s Group Encrypted Transport VPN (GET VPN) introduces the concept of a trusted group to eliminate point-to-point tunnels and their associated overlay routing. All group members (GMs) share a common security association (SA), also known as a group SA. This enables GMs to decrypt traffic that was encrypted by any other GM. (Note that IPsec CE acts as a GM.) In GET VPN networks, there is no need to negotiate point-to- point IPsec tunnels between the members of a group, because GET VPN is ―tunnel-less.

● GDOI (RFC 3547)

● Key servers (KSs)

● GMs

● IP tunnel header preservation

● Group security association

● Rekey mechanism

● Time-based anti-replay (TBAR)

  
      The GDOI group key management protocol is used to provide a set of cryptographic keys and policies to a group of devices. In a GET VPN network, GDOI is used to distribute common IPsec keys to a group of enterprise VPN gateways that must communicate securely. These keys are periodically refreshed and are updated on all the VPN gateways using a process called rekey. The GDOI protocol is protected by a Phase 1 Internet Key Exchange (IKE) SA. All participating VPN gateways must authenticate themselves to the device providing keys using IKE.
GDOI introduces two different encryption keys. One key secures the GET VPN control plane; the other key secures the data traffic. The key used to secure the control plane is commonly called the Key Encryption Key (KEK), and the key used to encrypt data traffic is known as Traffic Encryption Key (TEK).

  Tunnel Header Preservation
       In traditional IPsec, tunnel endpoint addresses are used as new packet source and destination. The packet is then routed over the IP infrastructure, using the encrypting gateway source IP address and the decrypting gateway destination IP address. In the case of GET VPN, IPsec protected data packets encapsulate the original source and destination packet addresses of the host in the outer IP header to preserve the IP address.
Used in wan, not suitable for internet.

Key Server (KS)
      A key server (KS) is an IOS device responsible for creating and maintaining the GET VPN control plane. All encryption policies, such as interesting traffic, encryption protocols, security association, rekey timers, and so on, are centrally defined on the KS and are pushed down to all GMs at registration time. GMs authenticate with the KS using IKE Phase 1 (pre-shared keys or PKI) and then download the encryption policies and keys required for GET VPN operation. The KS is also responsible for refreshing and distributing the keys. Unlike traditional IPsec, interesting traffic defined on the KS (using an access control list (ACL)) is downloaded to every GM, whether or not the GM owns that network.

Group Member (GM)
      A GM is an IOS router responsible for actual encryption and decryption i.e. a device responsible to handle GETVPN data plane. A GM is only configured with IKE phase 1 parameters and KS/Group information.

Group SA
       Unlike traditional IPsec encryption solutions, GET VPN uses the concept of group SA. All members in the GET VPN group can communicate with each other using a common encryption policy and a shared SA. With a common encryption policy and a shared SA, there is no need to negotiate IPsec between GMs; this reduces the resource load on the IPsec routers.
  Note: In a GET VPN group, up to 100 ACL permit entries can be used to define interesting traffic for encryption. Each permit entry results in a pair of IPsec SAs; the maximum number of IPsec SAs in a group cannot exceed 200.
  
  Rekey Process
      As mentioned above, the KS is not only responsible for creating the encryption policies and keys, but also for refreshing keys and distribute them to GMs. The process of sending out new keys when existing keys are about to expire, is known as the rekey process. GET VPN supports two types of rekey messages: unicast and multicast.
  If a GM does not receive rekey information from the KS (for example, the KS is down or network connectivity is broken), the GM tries to reregister to an ordered set of KSs 60 seconds before the existing IPsec SAs expire. If reregistration is successful, the GM receives new SAs as part of the reregistration process and traffic in the data plane flows without disruption. If reregistration is unsuccessful (the preferred KS is unavailable), the GM tries three more times, at 10-second intervals, to establish a connection with the KS.

  Unicast Rekey
       In the unicast rekey process, a KS generates a rekey message and makes multiple copies of the message, one copy to each GM. Upon receiving the rekey message, a GM sends an ACK message to the KS. This ACK mechanism not only ensures that the list of active GMs on the KS is current, but also ensures that the rekey message is sent only to active GMs.
If a GM does not acknowledge three consecutive rekeys (retransmissions are considered part of the rekey), the KS removes the GM from its active GM database and stops sending rekey messages to that GM.

Multicast Rekey
       In the multicast rekey process, a KS generates a rekey message and sends one copy of the message to a multicast group address that is predefined in the configuration. Each GM joins the multicast group at registration time, so each GM receives a copy of the rekey message. Unlike unicast rekey, multicast rekey does not have an ACK mechanism.

Time Based Anti-Replay (TBAR)
      GET VPN uses time-based anti-replay (TBAR), which is based on a pseudo-time clock that is maintained on the KS. An advantage of using pseudotime for TBAR is that there is no need to synchronize time on all the GET VPN devices using NTP. The primary KS is responsible for establishing and maintaining the pseudo-time for a group. The primary KS must also keep pseudotime synchronized on all GMs via rekey updates. Every GM includes its pseudo-time as a time stamp in the data packets. A receiving VPN gateway then compares time stamp of the received packet with the GM reference pseudotime clock it maintains for the group. If the packet arrived too late, it is dropped.

Fail-Close Mode
      Until a group member registers with a key server, traffic passing through the group member is not   encrypted. This state is called “fail open.” To prevent unencrypted traffic from passing through a group  member before that member is registered, you can configure the Fail-Close feature. If the feature is  configured, an implicit “permit ip any any” policy is installed, and all unencrypted traffic passing  through the group member is dropped (this state is called fail-close mode).

  

  • Group Encrypted Transport
  • Cisco  Proprietary
  • Compnents:
    • GDOI (Group Domain of Interpretation) [RFC 3547]
      • It is a protocol used to share keys
      • It runs on protocol UDP 848
      • ISAKMP Phase 1 protects GDOI
      • GDOI has 2 keys:
        • Key Encryption Key (KEK) [KS --> GM]
        • Traffic Encryption Key (TEK) [GM <--> GM]
    • Key Servers (KS)
      • It generates Keys for encryption
      • It is used for policy generation, which guides as to which traffic needs to be encrypted and what encryption algorithm to use
    • Group Member (GM)
    • Rekeying
      • It is a process of retransmission of keys by Key Server
      • There are 2 types:
        • Unicast: Where KS sends keys to GM and GM replies with ACK
        • Multicast: Where KS sends keys to multicast address 239.0.0.0 and GMs registered to that address receives it. No ACK!
    • Time based Anti Replay
      • It is a mechanism to prevent Replay attack
      • It uses metadata to create a psuedo clock which times the time between transmission and reception.
      • IPSec sequence number technique does not work because in GET VPN a group SA is formed and the communication happens with multiple GM's and the sequence numbers will not be continuous
    • IP Header preservation makes a copy of the Tunnel IP header and uses it in the IP (Hence not suitable on the Internet, to be used only on WAN.
TASK: Configure GET VPN for the topology given below:

  1. Please do the initial configuration on the routers by assigning ip addresses as shown above
  2. Please define static routes on all the devices such that R3 and R4 should know the R1 ip address of 10.1.12.1 (Key Server) and should use R2 as the next hop to reach each other's loopback address
  3. Please note: Due to the IP Address preservation property of GET VPN (as defined above), R2 needs to know routes to the loopbacks of R3 and R4

Let us first start with Key Server Configuration
First let us generate an RSA 1024 length key
  • R1(config)# ip domain-name cisco.com
  • R1(config)# crypto key generate rsa modulus 1024 label GET_KEY
Now let us start configuration for Phase 1 - ISAKMP Policy
  • R1(config)# crypto isakmp policy 10
    • R1(isakmp-policy)# authentication pre-share
  • R1(config)# crypto isakmp key 0 GET_R3 address 10.1.23.3
  • R1(config)# crypto isakmp key 0 GET_R4 address 10.1.24.4
Now let us configure the Phase 2 - IPSec Transformset and Profile
  • R1(config)# crypto ipsec transform-set TSET esp-3des esp-sha-hmac
  • R1(config)# crypto ipsec profile GET_PRO
    • R1(ipsec-profile)# set transform-set TSET
Now it is time to configure the Key Server
  • R1(config)# crypto gdoi group GET_VPN
    • R1(config-gdoi-group)# identity number 134
    • R1(config-gdoi-group)# server local // At this point the GDOI will get enabled
      • R1(gdoi-local-server)# rekey authentication mypubkey rsa GET_KEY
      • R1(gdoi-local-server)#  rekey retransmit 10 number 2
      • R1(gdoi-local-server)#  rekey transport unicast
      • R1(gdoi-local-server)#  authorization address ipv4 GM-LIST // A standard ACL with a list of Group Member's IP Address
      • R1(gdoi-local-server)#  address ipv4 10.1.12.1 // Key Server's IP Address
      • R1(gdoi-local-server)#  sa ipsec 1
        • R1(gdoi-sa-ipsec)# profile GET_PRO
        • R1(gdoi-sa-ipsec)#  match address ipv4 LAN_LIST // The extended ACL controlling traffic (to be encrypted or not)
        • R1(gdoi-sa-ipsec)#  replay counter window-size 64  
  • R1(config)# ip access-list standard GM_LIST
    • R1(config-std-nacl)# permit 10.1.23.3
    • R1(config-std-nacl)# permit 10.1.24.4
  • R1(config)# ip access-list extended LAN_LIST
    • R1(config-ext-nacl)# deny udp any eq 848 any eq 848 // Telling the GM's not to encrypt traffic between GM and KS
    • R1(config-ext-nacl)# permit ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255 // The interesting traffic between loopbacks of GMs
Now let us configure the Group Member
Please Note: The beauty of GET VPN is that the configuration on all the GMs are identical! The only change in configuration is for the peer password. In the following commands 'Rx' denotes both R3 and R4.
  • Rx(config)# crypto isakmp policy 10
    • Rx(isakmp-policy)# authentication pre-share
  • R3(config)# crypto isakmp key 0 GET_R3 address 10.1.12.1
  • OR
  • R4(config)# crypto isakmp key 0 GET_R4 address 10.1.12.1
  • Rx(config)# crypto gdoi group GET_VPN
    • Rx(config-gdoi-group)# identity number 134
    • Rx(config-gdoi-group)# server   address ipv4 10.1.12.1
  • Rx(config)# crypto map CMAP 10 gdoi
    • Rx(config-crypto-map)# set group GET_VPN
  • Rx(config)# interface f0/0
    • Rx(config-if)# crypto map CMAP // As soon as you apply the map to the interface, GDOI negotiation will happen with the KS as shown in syslog
Verification Commands
R1#sh crypto gdoi group GET_VPN
       Group Name                             : GET_VPN (Unicast)
       Group Identity                     : 134
       Group Members                       : 2
       IPSec SA Direction             : Both
       Active Group Server           : Local
       Group Rekey Lifetime         : 86400 secs
       Group Rekey
               Remaining Lifetime     : 82712 secs
       Rekey Retransmit Period   : 10 secs
       Rekey Retransmit Attempts: 2
       Group Retransmit
               Remaining Lifetime     : 0 secs

           IPSec SA Number               : 134
            IPSec SA Rekey Lifetime: 3600 secs
           Profile Name                     : GET_PRO
           Replay method                   : Count Based
           Replay Window Size         : 64
           SA Rekey
                 Remaining Lifetime   : 2375 secs
           ACL Configured                 : access-list LAN_LIST

       Group Server list               : Local

R1# sh cry isa sa
IPv4 Crypto ISAKMP SA
dst                  src                 state                  conn-id   slot status
10.1.12.1             10.1.23.3             GDOI_IDLE                 1006       0     ACTIVE
10.1.12.1             10.1.24.4             GDOI_IDLE                 1007       0     ACTIVE

IPv6 Crypto ISAKMP SA

R1#sh cry ips sa

No SAs found   // This is because there is no encrypted traffic between KS and GM

R3# sh cry isa sa
IPv4 Crypto ISAKMP SA
dst                  src                state                   conn-id slot status
10.1.12.1             10.1.23.3             GDOI_IDLE                 1006      0     ACTIVE

IPv6 Crypto ISAKMP SA

R4# sh cry isa sa
IPv4 Crypto ISAKMP SA
dst                  src                state                   conn-id slot status
10.1.12.1             10.1.24.4        GDOI_IDLE                 1007      0     ACTIVE

IPv6 Crypto ISAKMP SA

TASK: Configure GET VPN for the topology with ASA as given below:

  • Make the initial configurations of the IP addresses as shown
  • GM1, GM2 and GM3 should know the route to reach 100.1.1.100 of KS. Open respective ACLs in ASA for UDP 848 (GDOI)
  • All the GMs should use ASA as the next hop for the other GM's loopback and ASA should know the routes to all the loopbacks
  • PLEASE NOTE: Normally with ASA and VPN, we have 2 critical ACLs: UDP 500 (ISAKMP) and ESP. In GET VPN, UDP 500 is mutated to UDP 848 (GDOI). Hence we do not need an ACL for UDP 500!
Let us first start with Key Server Configuration
First let us generate an RSA 1024 length key
  • KS(config)# ip domain-name cisco.com
  • KS(config)# crypto key generate rsa modulus 1024 label GET_KEY
Now let us start configuration for Phase 1 - ISAKMP Policy
  • KS(config)# crypto isakmp policy 10
  • KS(isakmp-policy)# authentication pre-share
  • KS(config)# crypto isakmp key 0 GET_GM1 address 10.1.1.1
  • KS(config)# crypto isakmp key 0 GET_GM2 address 20.1.1.2
  • KS(config)# crypto isakmp key 0 GET_GM3 address 30.1.1.3
Now let us configure the Phase 2 - IPSec Transformset and Profile
  • KS  (config)# crypto ipsec transform-set TSET esp-3des esp-sha-hmac
  • KS  (config)# crypto ipsec profile GET_PRO
    • KS  (ipsec-profile)# set transform-set TSET
Now it is time to configure the Key Server
  • KS  (config)# crypto gdoi group GET_VPN
    • KS  (config-gdoi-group)# identity number 123
    • KS  (config-gdoi-group)# server local  // At this point the GDOI will get enabled
      • KS  (gdoi-local-server)# rekey authentication mypubkey rsa GET_KEY
      • KS  (gdoi-local-server)#  rekey retransmit 10 number 2
      • KS  (gdoi-local-server)#  rekey transport unicast
      • KS  (gdoi-local-server)#  authorization address ipv4 GM-LIST  // A standard ACL with a list of Group Member's IP Address
      • KS  (gdoi-local-server)#  address ipv4 100.1.1.100  // Key Server's IP Address
      • KS  (gdoi-local-server)#  sa ipsec 1
        • KS  (gdoi-sa-ipsec)# profile GET_PRO
        • KS  (gdoi-sa-ipsec)#  match address ipv4 LAN_LIST  // The extended ACL controlling traffic (to be encrypted or not)
        • KS  (gdoi-sa-ipsec)#  replay counter window-size 64  
  • KS  (config)# ip access-list standard GM_LIST
    • KS  (config-std-nacl)# permit 10.1.1.1
    • KS  (config-std-nacl)# permit 20.1.1.2
    • KS  (config-std-nacl)# permit 30.1.1.3
  • KS  (config)# ip access-list extended LAN_LIST
    • KS  (config-ext-nacl)# deny udp any eq 848 any eq 848  // Telling the GM's not to encrypt traffic between GM and KS
    • KS  (config-ext-nacl)# permit ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255  // The interesting traffic between loopbacks of GMs
Now let us configure the Group Member
Please Note:  The beauty of GET VPN is that the configuration on all the GMs are identical! The only change in configuration is for the peer password. In the following commands 'GMx' denotes both GM1, GM2 and GM3.
  • GMx(config)# crypto isakmp policy 10
    • GMx(isakmp-policy)# authentication pre-share
  • GM1(config)# crypto isakmp key 0 GET_GM1 address 100.1.1.100
  • OR
  • GM2(config)# crypto isakmp key 0 GET_GM2 address 100.1.1.100
  • OR
  • GM3(config)# crypto isakmp key 0 GET_GM3 address 100.1.1.100
  • GMx(config)# crypto gdoi group GET_VPN
    • GMx(config-gdoi-group)# identity number 123
    • GMx(config-gdoi-group)# server   address ipv4 10.1.12.1
  • GMx(config)# crypto map CMAP 10 gdoi
    • GMx(config-crypto-map)# set group GET_VPN
  • GMx(config)# interface f0/0
    • GMx(config-if)# crypto map CMAP  // As soon as you apply the map to the interface, GDOI negotiation will happen with the KS as shown in syslog
Please make sure you have the following Access Lists in the ASA:
access-list OUT1_IN extended permit udp host 10.1.1.1 eq 848 host 100.1.1.100 eq 848
access-list OUT1_IN extended permit esp host 192.168.1.1 any
access-list OUT2_IN extended permit udp host 20.1.1.2 eq 848 host 100.1.1.100 eq 848
access-list OUT2_IN extended permit esp host 192.168.2.2 any
access-list OUT3_IN extended permit udp host 30.1.1.3 eq 848 host 100.1.1.100 eq 848
access-list OUT3_IN extended permit esp host 192.168.3.3 any  

And the following Access Groups:
access-group OUT1_IN in interface OUTSIDE1
access-group OUT2_IN in interface OUTSIDE2
access-group OUT3_IN in interface OUTSIDE3

KEK resend and delete of GM registrations.JPG